Telecommunications providers and others are in the process of deploying wide-scale ‘triple-play’ networks to provide subscribers with Internet communications, streaming video, and streaming audio—including voice communications in a single subscription service. Many of these triple-play networks use the Internet Protocol (IP) to deliver video services, and since in some cases communications bandwidth to individual subscriber's homes is implemented using very high bit-rate DSL (VDSL), it is useful to monitor subscriber's IP video service quality to, among other things, quickly detect network problems and perform trouble-shooting of the network and video delivery mechanisms.
Video may be delivered over these networks using the real-time protocol (RTP). This protocol breaks up a media stream, such as, for example, an MPEG-2 video stream, into a series of separate packets that are then routed through a network to a subscriber's IP video receiver. Because the RTP packets are not transmitted synchronously, but rather are routed individually through the network, certain packets may be lost, delayed, delivered out of sequence, become corrupted, or suffer other mishaps. While these kinds of mishaps can occur in other applications, such as e-mail communication, they are particularly noticeable in the delivery of video and audio streams. There are further technical challenges to the delivery of such streamed information in view of the large amount of information that is contained in the video stream and that must be assembled very quickly and reliably into a video presentation by the IP video receiver. Accordingly, even very limited amounts of defective or late routing of relatively few RTP packets may cause a noticeable and annoying degradation of video quality from the point of view of the user.
There exists tools that can be included in video receiving equipment that can monitor the video path delivery performance and detect the various problems that may affect packet delivery such as loss, delay, disordering, and the like. However, these tools capture information in terms of RTP packet delivery, rather than in terms of the actual video quality as presented by the IP video receiver. While sometimes useful as a rough approximation of video delivery quality, these tools do not take into account the fact that IP video receiving equipment usually buffers a significant number of RTP packets in memory, providing a window of opportunity for late or out of order RTP packets to arrive before the video content they contain must be decoded and presented as video. In addition, many IP video receivers include packet loss recovery mechanisms, whereby missing RTP packets can be requested and, hopefully, received during the interval between the time the missing packet should have been received and the time that it would need to be available for decoding into video. Finally, the amount of video impairment caused by the loss, delay, disordering, corruption, etc of RTP packets is not uniform, but may depend on the content of the packet. For example, a packet containing important video control information or parts of important “I” MPEG frames, if despite efforts at error recovery, is not available in time for its video decoding, will cause a comparatively more severe disruption in video quality than the loss of a packet containing only a small part of a less significant “P” MPEG frame. It is these kinds of subtleties of delivery quality in terms of the video presented by the IP video receiver that tools, which track only the video path performance at the level of RTP packet delivery, are unable to detect. Moreover, some of these tools are designed to be installed at the video head-end or video server and thus may not scale up to the large number of subscribers envisioned for triple-play networks.
A technique that can be used to monitor the quality of video as ultimately presented to the user involves capturing the actual video stream as presented by the user (after buffering, packet loss recovery, decoding, etc) and transmitting it back upstream to the sender of the video (e.g., a multicast or unicast video server) or some other video quality monitoring tool. In this way, the video as ultimately presented by the IP video receiver can be compared directly with the video as transmitted to the IP video receiver by the transmitter. However, this technique usually cannot be implemented successfully because VDSL usually has limited upstream bandwidth, this limited bandwidth not being sufficient to transmit back the actual video stream as presented to the user.